\section{Suggestions, Questions and Remarks} \label{sec:suggestions}
Users and developers made a lot of good suggestions, this chapter is an incomplete list of them.

Some word of warning: this is an open source project, as such its developer(s) are not so much interested in selling the framework to as many people as possible, but on having fun writing something cool. Hence some things that people would like to have will never be implemented because the developers don't have fun doing this stuff. 

\subsection{Version 1.0.7}

\subsubsection{Of people using the library}

\begin{itemize}
 \qaf{When showing tabs, would it be possible to show a drop-down menu when there is not enough space for all the tabs?}{This will be implemented and has high priority.}{The \src{TabLayoutManager} is responsible for deciding which actions to place in the overflow-menu and which not. Clients may use \src{TabPane.LAYOUT\_MANAGER} to set their own implementation.}
 
 \qaf{Tabs: would it be possible to show them on the left, right, bottom, top rotate etc...?}{Whilst it would be easy to just put them at another place, there needs more to be done. This feature requires to upgrade most of the painting code. In theory the \src{StackDockComponent} would already provide developers with the ability to use their very own tabs (at their own place), but not to reuse the existing tabs. More settings would be a nice improvement of the framework and will most certainly be implemented.}{Use \src{StackDockStation.TAB\_PLACEMENT} to set the side on which to show tabs.}
 
 \qa{AWT, it needs better support (e.g. things should be painted over AWT panels as well).}{AWT and Swing don't work together. This framework is based on Swing, any attempt to support AWT will result in a lot of ugly hacks. Also given the fact that AWT isn't hardly used anymore (except for applications playing video or rendering 3D scenes) this feature has little to none chances of getting implemented.}
 
 \qaf{Could the framework be made available for [insert your favorite tool here]? E.g. in a Maven repository or for the Netbeans GUI Builder.}{Making the framework available in/for any special tool immediately yields two new problems. First, as soon as one tool is supported people will ask for another tool, this will never end... Second, a library does no get better because it does support many other tools, it does get better because it has lesser bugs, more settings or features.}{Andrei Pozolotin set up a Maven repository, for other tools the answer remains the same.}
 
 \qaf{Assume an externalized \src{CDockable}, if it gets maximized, could it be maximized like a \src{JFrame}? It would will the entire screen instead of falling back to the nearest \src{CContentArea}.}{This is a good idea. It is not yet clear how to implement this, but it is among those things that will be done.}{That is now the default behavior. With \linebreak \src{ScreenDockStation.FULL\_SCREEN\_STRATEGY} clients can influence what exactly ``full screen'' means.}
 
\end{itemize}

\subsubsection{Of the developers}
Since the framework has its own forum many questions have been asked, and most of them were answered as well. From these questions some observations can be made:

\begin{itemize}
 \item Problems arise both in \src{Core} and in \src{Common}. The problems are however of different nature. In \src{Core} most problems concern small things, e.g. how to place the tabs. Most of these problems can be solved with small patches. 
 
 The problems related to \src{Common} are a lot more serious. Often the answer is ``\src{Common} is not able to do that''. And even worse, there is often no small patch. In short: \textit{\src{Common} has serious design flaws}. Especially \src{Common} lacks the ability to customize components.
 
 Hence most future work must be spent on \src{Common}.
 
 \item The features now available seem to be sufficient for most applications. The requests for things that are entirely missing has dropped to almost zero. There is no need for new features, there is need to improve existing features.
\end{itemize}

Putting the pieces together the areas that will make the framework better are most likely:
\begin{itemize}
 \item The \src{StateManager}, this class is responsible for managing the ``extended mode''. The class has continually grown and has become a major hindrance for customization. Currently there is absolutely no abstraction in this class, it needs to redesigned from scratch. This class is almost as important as \src{DockController} or \src{CControl}, its redesign will affect a lot of other classes. The effect will be, that a) any station can have any function, or many functions at the same time (e.g. minimizing could be mapped to a custom component). And b) clients would be able to introduce their very own extended modes.
 \item \src{CControl} and other classes use a lot of anonymous classes. They need to be named and made public, and clients need to be able to exchange them by their own implementations. New factories, also factories with customizable properties, could help.
 \item Clients need more control over \src{CDockable}s, or better their representation as \src{Dockable}. One possibility would be a second series of \src{CDockable}s that extend directly \src{DefaultDockable}.
 \item There should also be more observers, clients should be able to register and react (or cancel) to almost all actions of the framework.
\end{itemize}
 
\subsection{Version 1.0.8}
\subsubsection{Of people using the library}
\begin{itemize}
  \qa{Will there be support for Maven?}{Andrei Pozolotin created a maven repository. You can find information about it on \url{http://code.google.com/p/docking-frames/}}.
  \qa{The guides and documentation are not helpful: they are incomplete, do not start with the basics and do not build upon each other.}{It is completely understandable that starting with this framework is not that easy. The guides are intended to provide background information about tasks that often need to be done. There clearly is a gap between background information and practice. To close the gap a set of example applications will be included in the next version (some of them are already packed together with this version). These examples will be executable. }
  \qa{The code snippets in the guides are too small.}{In future releases there will be an example in the example-project for most snippets.}
  \qa{How do I create a layout (a ``perspective'').}{If the placeholder mechanism would contain some public API, then this could be easily solved. Unfortunatelly such an API does not yet exist, but is on the todo-list.}
\end{itemize}


\subsubsection{Of the developers}
Some of the issues of 1.0.7 have been addressed. Mostly the \src{StateManager} got replaced by the \src{CLocationModeManager}. Customization still is an issue.

\begin{itemize}
 \item There is an annotation \src{Todo}, Interfaces, classes or methods that need to be changed are marked with this annotation.
 \item People often would like to set a new border or to slighly modify the current \src{DockTheme}. Currently such a task requires people to write several new classes. This is far from intuitive and not easy to accomplish, especially if someone does not know where to start. In order to solve the issue several changes will happen:
 \begin{enumerate}
  \item There will be class \src{ThemeManager} (or a similar name), this manager will provide a set of \src{PropertyKey}s. Using these keys clients will have the ability to override the settings of a theme without the need to subclass or even access the theme.
  \item The \src{ThemeManager} will  make use of \src{UIProperties} to distribute its content. This way clients can override settings for individual \src{Dockable}s.
 \end{enumerate}
 \item It is hard to start with the framework. And it is nearly impossible to use some of the advanced stuff. In order to help people finding their way, the next version will include a set of examples. There may be between 20 to 30 examples, each example will be an executable application showing and explaining how to accomplish some task.
 \item The framework would support unsigned applets and webstart applications. But clients need to use special ``secure'' classes. This is an obstacle: it forces the use of factories at locations where factories do not improve the framework. Also subclassing is broken because there are two classes esentially doing the same, but not being the same. For these reasons the ``secure'' package will be removed in the next version. Instead classes will get the ability to switch between ``secure'' and ``normal'' behavior even after they were created.
\end{itemize}


\subsection{Version 1.1.0}
\subsubsection{Of the people using the framework}
This time there is no question that is asked by many people. Almost all questions are about little things. So the list below contains only some example questions.
\begin{itemize}
 \qa{When will the framework be bugfree?}{Never. But the number of bugs is slowly decreasing. Your questions and bug reports can help speeding up that process. Always include the stacktrace (yes, really, you might not have guessed but they so much help finding bugs...)} and/or a description how to reproduce the bug.
 \qa{What about transparent background?}{Does not have a high priority, as transparancy can already be simulated.}
 \qa{How does the \src{CGrid} work, how do I add or remove \src{Dockable}s from a \src{CControl}.}{There is still much confusion about the \src{CGrid}. \src{CGrid} can be used one time to setup the initial layout, afterwards the method \linebreak \src{setVisible} of \src{CDockable} has to be used to make new \src{Dockable}s visible. You need to add (\src{addDockable}) any \src{Dockable} to the \src{CControl} unless you added it through the \src{CGrid}.}
\end{itemize}

\subsubsection{Of the developers}
With version 1.1.0 the framework moves from ``beta'' to ``release''. There were many small enhancements, notably the complete elimination of the ``secure'' packages and the introduction of perspectives.
\begin{itemize}
 \item Customization is now much easier due to existence of the \src{ThemeManager} and the various subclasses of \src{UIProperties}. What remains missing are some examples how to use the new features, this will be addressed in version 1.1.1.
 \item A lot small ``todo''s have been collected in version 1.1.0, and version 1.1.1 is mostly dedicated on solving this open issues.
 \item While perspectives are already a powerfull tool they lack features like exporting/importing from a file and an easy way to modify them.
 \begin{enumerate}
  \item Ideally clients should be able to define a default perspective, modify the perspective (e.g. adding additional \src{Dockable}s) and the framework would extrapolate the current layout by comparing the original default perspective with the modified one. If and how this feature could be supported is yet open to debate.
  \item An editor to inspect and modify the perspectives of an application might also be a handy tool. At the moment this is more science fiction than reality.
 \end{enumerate}
\end{itemize}

\subsection{Version 1.1.1}
\subsubsection{Of the people using the framework}
In the year of working on 1.1.1, there were a lot questions that could be answered without the need of modifying the framework. Many people reported bugs, and they were fixed whenever possible. As good as all feature requests could be implemented. Below are the three most prominent open questions:
\begin{itemize}
 \qa{There seems to be some issues with focus.}{Yes, the focus system still has issues. Some code has been replaced during development of 1.1.1, a few border cases have been resolved. And the new \src{FocusStrategy} tracks the last focused child \src{Component} of each \src{Dockable}. But all in all the focus system still does not work fully satisfying, this construction site will remain open for a long time.}
 \qa{How well is fullscreen support?}{It's a lot better than in earlier versions, some issues may still appear. For example a maximized \src{ScreenDockWindow} may cover the taskbar. It is not yet clear how to fix these issues.}
 \qa{What is with the Eclipse 4.x theme?}{The original plan was to include a theme looking like Eclipse 4.x in version 1.1.1, but instead the Toolbar Extension got included. The theme is now scheduled to appear in 1.1.2.}
\end{itemize}
\subsubsection{Of the developers}
The unexpected introduction of the Toolbar Extension created a lot of work. As a result the core of \src{DockingFrames} did not get as much love as in previous versions. But then looking at the feedback from other developers, most issues nowadays fall in the area of ``minor annoyances''. Sure, there are still bugs, but they do no longer stop entire applications from working.
\begin{itemize}
 \item New features, like the animations during drag and drop, have purely asthetic value. They do make the framework ``better'', but they don't add anything that is critical. Future versions will have even more maintenance, and less new features.
 \item Streamlining various interfaces was a good thing, it adds more flexibility and less possibilities for errors in how to implement some modules like the \src{DockStation}s.
 \item The big new thing of course is the Toolbar Extension. Many modifications, for example the configuration of \src{ScreenDockWindow}s, are a direct result of supporting the extension. The extension itself is not yet finished, new bugs and missing features will certainly provide work for a long time.
\end{itemize}
